home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / parttext-richtext153 < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.8 KB  |  107 lines
  1. <paragraph>
  2. In a previous message, R. Raisch proposed a number of interesting
  3. link types.  One of them was the attention link, which I want to
  4. discuss here.  I am uncertain about the need for this link, the
  5. technical ability to provide it, and the definition.
  6.  
  7. <nl>
  8. <paragraph>
  9. Let me discuss the function first.  The function seems to be
  10. providing a means of notifying an "owner" of a document when certain
  11. conditions obtain.  The conditions Raisch mentions are:<nl>
  12. <indent>
  13.  1) someone has read the document<nl>
  14.  2) someone has modified the document<nl>
  15. </indent>
  16.  
  17. <nl><paragraph>
  18. There is some doubt in my mind about read notifications.  I am not sure I
  19. want other people to know what I read.  I can see only two reasons
  20. for this feature:<nl>
  21. <indent>
  22.  1) as a form of "proof of delivery".  Some email systems provide
  23. this, but I don't like it.<nl>
  24.  2) as a means of collective revenue (pay-per-read)<nl>
  25. </indent>
  26.  
  27. <nl><paragraph>
  28. As for charging, fairness requires that the link not be activated
  29. until I have seen a warning (otherwise I might get charged a zillion
  30. dollars to read the document - just like 900 phone numbers in the
  31. USA).  So this will add complexity to the client.
  32.  
  33. <nl><paragraph>
  34. Also, attention links are not sufficient for a charging.  They
  35. support a model where I am charged once per read, no matter how much
  36. of the document I read.  But it seems likely that there might be need
  37. for other charging models.  It is also unclear that they are technically
  38. sufficient.  For economic purposes, you would want the message to be sent
  39. by the server, not the client.  But this would cease working if the
  40. document were copied.  (But maybe this is not a fair objection, since
  41. I know of no scheme that can preserve property rights given the
  42. possibility of perfect digital  copying.)
  43.  
  44. <nl><paragraph>
  45. Continuing on the more general question of read notification,
  46. regardless of purpose, it is possible that one might desire
  47. notification on a finer grain that the entire document.  But this, I
  48. think, requires the cooperation of the client.  Indeed, the client
  49. can tell the server that a given piece of text has been displayed,
  50. but not whether the user actually read it (unless we go further, and
  51. implement it with an executable function which requires the user to
  52. click on a button)
  53.  
  54. <nl><paragraph>
  55. As for the second form (modification notification), it seems to me
  56. that there is a need to inform not just the owner, but also other
  57. people.  There are two reasons for this:  
  58.  
  59. <nl><paragraph>
  60. First, as owner of a document, I am not likely to allow other people
  61. to modify my document at all.  On the other hand, I might be
  62. interested in notifications when someone adds or deletes a link <bold>to</bold>
  63. my document.  But attention links don't address this problem.
  64.  
  65. <nl><paragraph>
  66. Second, as a reader of a document I don't own, I might want to be
  67. notified when the owner modifies it, since I might wish to re-read it
  68. (or at least the changed sections.)  Let's call these "monitor"
  69. links.  Monitor links might be a useful means of reducing effort
  70. required for some kinds of network retrievals - those where I am
  71. interested in new developments in certain areas.  Now, instead of
  72. polling documents to see whether they've changed, I can just leave an
  73. "attention link" and get a notification.
  74.  
  75. <nl><paragraph>
  76. On the other hand, this has some problems.  One of them is the
  77. question of who pays the cost of sending all these notifications.
  78. Can you imagine the load on your workstation as it sends out 10,000
  79. monitor notifications?  Perhaps this can be answered by bringing in
  80. more economics - that is, to attach a monitor link I need to set up
  81. an account such that I can be charged for the delivery.  Or maybe the
  82. notifications are sent by the document server, so as an author I am
  83. not affected.
  84.  
  85. <nl><paragraph>
  86. A second problem (or at least issue) is that monitor links require
  87. finer grain of size and time.  Some users will want to monitor only
  88. select portions of a document.  Likewise, we may not want
  89. notifications sent when <italic>any</italic> editing is made, but
  90. rather only when the author completes a session.  That is, if I edit
  91. the document for a day, saving changes six times, you don't want six
  92. notifications.  This might require some notion of "transactions" such
  93. as used in data bases.  
  94.  
  95. <nl><paragraph>
  96. Finally though, I don't think it is correct to call these things
  97. links.  They are not related to logical structure, nor are they
  98. explicitly activated by the reader (or writer), indeed that person
  99. not even be aware that it was activated.  Consider the more general
  100. question - if attention links are a subcase of execution links, and
  101. attention links can be activated without knowledge of the user,
  102. should all  execution links be capable of such activation?  Do you
  103. want to read documents which can cause arbitrary computations to
  104. occur without your choice, or even knowledge?
  105.  
  106.  
  107.